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(54) Method and apparatus for managing computer processes 



(57) A number of methods, apparatus, and data 
structures are disclosed for managing computer proc- 
esses. In one aspect, a daemon process which manag- 
es server processes includes an active server table and 
a locator service. The locator service can look up and 
register server processes in the active server table. Fur- 
thermore, the locator service can start up server proc- 
esses. In some embodiments, the locator service in- 
cludes a look-up object and a server process registra- 
tion object which perform the tasks of the locator serv- 
ice. In other embodiments, methods for managing serv- 
er process such as starting and registering the server 
processes are taught. In one specific method, a daemon 
process performs a variety of steps in response to re- 
ceiving a look-up call for a target object. These steps 



include obtaining a server identifier for the target object, 
determining the state of a server process, and returning 
addressing information corresponding to the server 
process under which the target object will activate. In 
related method aspects the daemon process will start 
the server process if it isn't running and/or wait until the 
server process is running to return the addressing infor- 
mation. In a separate method aspect, a server process 
self-starts; receiving an object reference for a desired 
target object, receiving a server process identification 
number, creating a communications port lor itself, form- 
ing addressing information for itself, obtaining an object 
reference for a server process registration object, and 
registering itself by calling the server process registra- 
tion object to invoke a register new process operation. 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object-oriented programming. More specifically, the 
present invention teaches methods, apparatus, and da- 
ta structures for managing computer processes. 

Object oriented programming methodologies have 
received increasing attention over the past several 
years in response to the growing tendency for software 
developed using traditional programming methods to be 
delivered late and over budget. This stems from the fact 
that traditional programming techniques which empha- 
size procedural models and "linear" code tend to be dif- 
ficult to design and maintain in many circumstances. 
Generally, large programs created using traditional 
methods are "brittle". That is, even small changes can 
effect numerous elements ot the programming code. 
Thus, minor changes made to the software in response 
to user demands can require major redesign and rewrit- 
ing of the entire program. 

Object oriented programming strategies tend to 
avoid these problems because object methodologies fo- 
cus on manipulating data rather than procedures; thus 
providing the programmer with a more intuitive ap- 
proach to modeling real world problems. In addition ob- 
jects encapsulate related data and procedures so as to 
hide that information from the remainder of the program 
by allowing access to the data and procedures only 
through the object's interface. Hence changes to the da- 
ta and or procedures of the object are relatively isolated 
from the remainder of the program. This provides code 
that is more easily maintained as compared to code writ- 
ten using traditional methods, as changes to an object's 
code do not affect the code in the other objects. In ad- 
dition, the inherent modular nature of objects allows in- 
dividual objects to be reused in different programs. 
Thus, programmers can develop libraries of "tried and 
true" objects that can be used over and over again in 
different applications. This increases software reliability 
while decreasing development time, as reliable pro- 
gramming code may be used repeatedly. 

A more recent advance in the field of object oriented 
methodologies has been the implementation of distrib- 
uted object operating environments over computers in- 
terconnected via a computer network. As used herein, 
the term "distributed object" or "object" refers to an en- 
capsulated package of code and data that can be ma- 
nipulated by operations through an interface. Thus, dis- 
tributed objects will be seen by those skilled in the art 
ot object oriented programming (OOP) as including the 
basic properties that define traditional programming ob- 
jects. However, distributed objects differ from traditional 
programming objects by the inclusion of two important 
features. First, distributed objects are multilingual. That 
is, the interfaces of distributed objects are defined using 



an interface definition language that can be mapped to 
a variety of different programming languages. One such 
interface definition language is IDL Second, distributed 
objects are location-independent, i.e., distributed ob- 

5 jects can be located anywhere in a network. This con- 
trasts sharply with traditional programming objects 
which typically exist in a single address space. 

Distributed objects can be object clients or object 
servers, depending upon whether they are sending re- 

10 quests to other objects or replying to requests from cli- 
ents. In a distributed object environment, requests and 
replies are made through an Object Request Broker 
(ORB) that is aware of the locations and status of the 
objects. One architecture which is suitable for imple- 

?s menting such an ORB is provided by the Common Ob- 
ject Request Broker Architecture (CORB A) specifica- 
tion. The CORBA specification was developed by the 
Object Management Group (OMG) to define the distrib- 
uted computing environment world in terms of objects 

20 in a distributed client-server environment, where server 
objects are capable of providing services to clients re- 
questing the service. In the following discussion, the 
terms "object" and "distributed object" will be used in- 
terchangeably. 

25 When a client calls a target object, certain proce- 
dures must be performed to ensure that the target object 
can perform the requested service(s). These proce- 
dures include identifying and locating the target object, 
starting the server process (if necessary) under which 
30 the target object resides, activating the target object if 
necessary, and, finally, establishing a connection with 
the target object and passing the call. The ORB would 
be ideal for managing server processes at all stages, 
including starting and registering the 0 server process- 
es es. What is needed is a framework for managing server 
processes under a distributed object operating environ- 
ment. 

SUMMARY OF THE INVENTION 

40 

To achieve the foregoing and other objectives and 
in accordance with the purpose of the present invention, 
methods, apparatus and data structures for managing 
computer processes are taught. According to one as- 
45 pect of the invention a daemon process running on a 
host computer system in a distributed object operating 
environment includes an active server table and a loca- 
tor service. The active server table has a data structure 
for maintaining entries related to a multiplicity of server 
50 processes that are currently running on the host com- 
puter. These entries include a server identifier, a server 
process state, and server process addressing informa- 
tion. The locator service accesses the active server ta- 
ble to provide addressing information about the server 
55 processes to a client requesting this information. Fur- 
thermore, the locator service registers server processes 
into the active server table. 

In one embodiment, the daemon process also has 
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an object adapter database resident therein. In addition- 
al embodiments, the object adapter database is resident 
elsewhere in the distributed object operating environ- 
ment. One specific embodiment has the object adapter 
database in a separate process running on the host 
computer. The object adapter database includes data 
elements such as target object identifiers, server iden- 
tifiers each corresponding to at least one target object 
identifier, and object references, each object reference 
corresponding to a target object identifier. In further em- 
bodiments, the locator service includes two objects, a 
locator object and a server process registration object. 
The locator object performs the server look-up function, 
and the server process registration object performs the 
server process registration function. A still further em- 
bodiment is contemplated wherein a distributed object 
operating environment includes a multiplicity of compu- 
ter systems connected by a network with a distinct dae- 
mon process as described above running on each one 
of the computer systems. 

In a separate aspect of the present invention, a 
computer system for use in a'distributed object operat- 
ing environment is contemplated. The computer system 
includes a central processing unit, memory accessed by 
the central processing unit, and a locator service imple- 
mented on the computer system. A plurality of distribut- 
ed objects reside in the memory. The locator service 
manages the distributed objects and any server proc- 
esses executing on the computer system. In several re- 
lated embodiments, the computer system will have 
means for performing the method aspects of the inven- 
tion as described below. 

In other aspects of the invention various methods 
for managing server processes such as starting and reg- 
istering server processes are disclosed. These server 
processes reside on a server host computer. In a first 
method, a daemon process resident on the server host 
computer performs the steps of receiving a look-up call 
for a target object, obtaining a server identifier for said 
target object, determining a state of a server process, 
and returning addressing information corresponding to 
said server process. The server process is uniquely de- 
fined within the server host computer by way of the serv- 
er identifier. In one method aspect, the server process 
state is determined to be running and, as a result, the 
step of returning said addressing information is per- 
formed immediately. In another method aspect, the 
state is determined to be starting and, as a result, the 
daemon process waits until the state transitions from 
starting to running before returning the addressing in- 
formation. 

In another method aspect, the step of obtaining a 
server identifier for the target object is performed by ac- 
cessing a first database. By way of example, the first 
database may be an object adapter database. Further- 
more, the state of the server process is determined by 
looking it up in a second database. In one example, the 
second database may be an active server table. In an- 



other embodiment, the first and the second databases . 
are the same database. 

In a still further method aspect, when the state of 
the process is determined to be not active (i.e. the server 

s process is not found in the second database), the dae- 
mon process creates a server process entry in the sec- 
ond database. This entry includes a server identifier and 
a server process state. The daemon process then con- 
tinues by marking the server process state as starting, 

to accessing the first database to get an execdef for the 
target object, starting the server process using the ex- 
ecdef, and waiting until the server process state transi-. 
tions from starting to running before returning the server 
process addressing information to the client. By way of 

is example, the execdef may be the server's program 
name and any necessary arguments. 

In yet another method aspect, the server process 
responds to being started by obtaining a server process 
identification number from the operating system of the 

20 host computer. Then it creates a communications port 
for the server process, forms addressing information for 
the server process, and then calls a server process reg- 
istration object resident in the daemon process. The op- 
eration of this call will invoke a register server operation. 

2S As arguments to this call, the server process passes the 
addressing information, the server process identifica- 
tion number, and the server identifier. In response to this 
call, the server process registration object stores the* ad- 
dressing information in the second database and marks 

30 the server process state entry as running. 

In another separate aspect of the invention, a self- 
start method for a server process (i.e. self -start and reg- 
ister) is taught. The method begins when the server 
process receives a request to become a server along 

3S with an object reference for the desired target object. In 
response the server process begins executing and ob- 
tains a server process identification number from the op- 
erating system of the host computer. Next it performs 
the steps of creating a communications port for the serv- 

*o er process, forming addressing information for the serv- 
er process, obtaining an object reference for a server 
process registration object from an object request bro- 
ker object file and calling the server process registration 
object to invoke a register new server operation. Then, 

4S in response to this call, the server process receives a 
server identifier corresponding to itself. 

BRIEF DESCRIPTION OF THE DRAWINGS 

so The invention, together with further objectives and 
advantages thereof, may best be understood by refer- 
ence to the following description taken in conjunction 
with the accompanying drawings in which: 

55 FIGURE 1 is a pictorial illustration of various com- 
puters linked together in a computer network. 

FIGURE 2 illustrates diagramatically the major 
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components of a computer in Figure 1 . 

FIGURE 3 is a pictorial illustration of a host-to-host 
client-server model showing the relationship be- 
tween a client running on a client host computer and s 
a server object running on a different, server host 
computer in a distributed object operating environ- 
ment; 

FIGURE 4 is a pictorial illustration of a process-to- 10 
process client-server model showing the relation- 
ship between a client and server running in different 
processes on a client/server host computer; 

FIGURE 5 is a pictorial illustration of a client-server is 
modei showing the relationship between a client 
and a server running in a single client/server proc- 
ess; 

FIGURE 6 is a pictorial illustration of a client-server 20 
interaction paradigm in accordance with the present 
invention, wherein an ORB daemon process man- 
ages server process startup and registration; 

FIGURE 7 is a pictorial illustration of an ORB dae- 25 
mon process in accordance with one embodiment 
of the present invention, the ORB daemon process 
including an active server table, a locator object, a 
server process registration object, and (optionally) 
an object adapter database; 30 

FIGURE 8 is a pictorial illustration of one embodi- 
ment of a data structure for the active server table 
of FIGURE 7, the data structure having multiple ac- 
tive server elements, each active server element in- 35 
eluding entries such as a server identifier, a server 
process state, server addressing information, and 
a server process identification number; 

FIGURE 9 is a flow chart illustrating a process ex- to 
ecuted by a client to invoke a distributed server ob- 
ject in accordance with one method aspect of the 
present invention; 

FIGURE 10 is a flow chart illustrating several pos- 45 
sible threads of execution of a locator object in ac- 
cordance with another method aspect of the 
present invention, in this aspect the locator object 
is performing a service in response to a look-up in- 
vocation; 50 

FIGURE 11 is a flow chart illustrating a thread of 
execution of a server process starting up in accord- 
ance with a further method aspect of the present 
invention; 55 

FIGURE 12 is a flow chart illustrating a thread of 
execution of a server process registration object in 



accordance with yet another method aspect of the 
present invention, in this aspect the server process 
registration object is performing a service in re- 
sponse to a register server invocation; 

FIGURE 13 is a flow chart illustrating a thread of 
execution of a server process "self-starting" in ac- 
cordance with a separate method aspect of the 
present invention; and 

FIGURE 14 is a flow chart illustrating a thread of 
execution of a server process registration object in 
accordance with another separate method aspect 
of the present invention, in this aspect the server 
process registration object is performing a service 
in response to a register new server invocation. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention relates to a distributed oper- 
ating environment based on object oriented program- 
ming (OOP). More specifically, this invention discloses 
methods, apparatus, and data structures for managing 
computer processes. In the following discussion, the 
methods and apparatus will be discussed in more detail, 
first through discussing example computer systems 
which are suitable for the present invention, next con- 
tinuing with a detailed description of several embodi- 
ments of the apparatus and data structures of the 
present invention, and then further through the detailed 
description of the method aspects of the present inven- 
tion. 

I. DEFINITION OF TERMS 

As used herein, the term "distributed object" or "ob- 
ject" refers to an encapsulated package of code and da- 
ta that can be manipulated by operations through a de- 
fined interface that is associated with an object. Thus, 
distributed objects will be seen by those skilled in the 
art as including the basic properties that define tradition- 
al programming objects. However, distributed objects 
differ from traditional programming objects by the inclu- 
sion of two important features. First, distributed objects 
are multilingual. The interfaces of distributed objects are 
defined using an interface definition language that can 
be mapped to a variety of different programming lan- 
guages. One such interface definition language is Ob- 
ject Management Group's (OMG) IDL Second, distrib- 
uted objects are location-independent, i.e., distributed 
objects can be located anywhere in a network. This con- 
trasts sharply with traditional programming objects 
which typically exist in a single address space. Distrib- 
uted objects can be object clients or object servers, de- 
pending upon whether they are sending requests to oth- 
er objects or replying to requests from other objects. Re- 
quests and replies are made through an Object Request 
Broker (ORB) that is aware of the locations and status 
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of the objects. 

A "distributed object system" or "distributed object 
operating environment' refers to a system comprising 
distributed objects that communicate through an ORB. 

An "object reference" or "objref" is an object that 
contains a pointer to another object For example, the 
objref may contain addressing information such as a 
host computer network address, an ORB daemon net- 
work port address and an object identifier. The creation 
and definition of object references will be familiar to 
those skilled in the art. 

A "client" as defined herein refers to an entity that 
sends a request to an object. In this model, the object 
receiving the request is referred to as a "server object" 
or a "target object". Thus, clients invoke operations, or 
implementations, from servers. In a distributed object 
environment, clients need not have knowledge of the im- 
plementation programming language, nor does the im- 
plementation have to have knowledge of the client's pro- 
gramming language due to the requirement of multilin- 
gual character of such objects. Clients and servers in 
distributed object environments need only communicate 
in terms of the interface definition language. As noted 
above, the request by the client to the server, and the 
server's reply to the client, is handled by the ORB. It 
should be pointed out that the client and server can exist 
within the same process, on the same host computer, 
or on two different host computers. 

An "object interface" is a specification of the oper- 
ations, attributes, and exceptions that an object pro- 
vides. Preferably, object interfaces for distributed ob- 
jects are written using IDL. As noted above, objects per- 
form transactions through their interfaces. The use of 
interfaces therefore relieves the need of objects that are 
aware of the programming languages used to define the 
methods and data of the objects in the transaction. 

To "marshal" a packet of information is to prepare 
this information for transfer over a network communica- 
tions line. This often means organizing the data in a par- 
ticular format in accordance with the network communi- 
cations protocol being used. 

To "unmarshaP a packet of information is to essen- 
tially reverse the marshaling procedure and produce da- 
ta in a format which is meaningful in a non-network en- 
vironment. 

II. Managing Distributed Objects and Computer 
Processes 

In a distributed object operating environment, re- 
quests and replies are made through an Object Request 
Broker (ORB) that is aware of the locations and status 
of the objects. One architecture which is suitable for im- 
plementing such an ORB is provided by the Common 
Object Request Broker Architecture (CORBA) specifi- 
cation. The CORBA specification was developed by the 
Object Management Group (OMG) to define the distrib- 
uted computing environment world in terms of objects 



in a distributed client-server environment, where target 
objects are capable of providing services to clients re- 
questing the service. In the following discussion, the 
terms "object" and "distributed object" will be used in- 
^ terchangeably, as the following invention is directed to 
both types. 

According to the present invention, the ORB is re- 
sponsible for managing many aspects of the distributed 
objects and the server processes found within the dis- 

10 tributed object operating environment, including client-, 
server interactions which involve calls to distributed ob- 
jects. Distributed objects, as contemplated by the 
present invention, are implemented (by the ORB and/or 
the host computer) under computer processes. As is 

15 well known to those skilled in the art, computer process- 
es provide a common framework under which computer 
systems function. 

In actuality, a process typically includes an address 
space (i.e. a portion of memory allocated to only the 

20 process), a set of file descriptors, a process identifica- 
tion number, and one or more threads of execution (of- 
ten referred to as threads). As is familiar to those skilled 
in the art, a single thread of execution is essentially a 
sequential flow of the point of execution through a proe- 
ms ess. Multi-threaded systems, such as the present inven- 
tion, allow for multiple threads to run concurrently In a 
single process. For a more detailed description' of 
threads, multi-threaded processes, and principles of 
concurrency, please see "Concurrency Within DOE Ob- 

30 ject Implementations" by Dr. Robert Hagmann, Version 
0.91, May 27, 1993, published by SunSoft and incorpo- 
rated herein by reference in its entirety. 

As a direct result of the framework of computer 
processes, all entities residing under a single process 

35 will share resources (Le. memory and files). Thus mul- 
tiple target objects residing in a single process will have 
efficient communication with one another. Furthermore, 
data can be loaded into memory that all objects residing 
in the single process will have access to. However, prd : 

to gramme rs may have other motivations (beyond efficient 
transport and data sharing) which negate the advantag- 
es gained by having many objects in a single process. 
For instance, different objects will have different objec- 
tives and may rely on different assumptions about the 

45 process. These motivations generate a need for orderly, 
multi-process distributed object operating environments 
as disclosed by the present invention. In allowing pro- 
grammers to keep objects within separate processes, 
the ORB may prevent conflict between and maintain the 

50 integrity of objects within processes. As a case in point- 
an object in a first server process may go into an error 
condition and begin chaotically writing within its server 
process memory. Nevertheless, objects running in sep : 
arate server processes will remain intact since these 

55 processes have their own memory, files, and flow con- 
trol. 

In a preferred embodiment of the present invention, 
distributed objects and computer processes are resi- 
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dent on one or more computers linked together by a net- 
work. The network may take any suitable form. By way 
of example, a representative network arrangement 10 
is illustrated in Fig. 1. The network arrangement 10 in- 
cludes a first computer 12 which is coupled to a trans- 
mission line 1 4. The network 1 0 further includes a serv- 
er, router or the tike 16 in addition to other computers 
18, 20, and 22 such that data and instructions can be 
passed among the networked computers. The design, 
construction and implementation of computer networks 
will be familiar to those of skill in the art. 

A representative computer 30 suitable for use as 
computers 12, 1B t 20, and/or 22 of Fig. 1 is illustrated 
schematically in Fig. 2. Computer 30 includes a central 
processing unit (CPU) 32 which is coupled bidirection- 
ally with random access memory (RAM) 34 and unidi- 
rectionally with read only memory (ROM) 36. Typically, 
RAM 34 is used as a "scratch pad" memory and includes 
programming instructions and data, including distribut- 
ed objects and their associated code and state, for proc- 
esses currently operating on CPU 32. ROM 36 typically 
includes basic operating instructions, data and objects 
used by the computer to perform its functions. In addi- 
tion, a mass storage device 38, such as a hard disk, CD 
ROM, magneto-optical (floptical) drive, tape drive or the 
like, is coupled bidirectionally with CPU 32. Mass stor- 
age device 38 generally includes additional program- 
ming instructions, data and objects that typically are not 
in active use by the CPU, although the address space 
may be accessed by the CPU, e.g., for virtual memory 
or the like. Each of the above described computers op- 
tionally includes an input/output source 40 that typically 
includes input media such as a keyboard, pointer devic- 
es (e.g., a mouse or stylus) and/or network connections. 
Additional mass storage devices (not shown) may also 
be connected to CPU 32 through a network connection. 
It will be appreciated by those skilled in the art that the 
above described hardware and software elements, as 
well as networking devices, are of standard design and 
construction, and will be well familiar to those skilled in 
the art. 

Returning to the discussion of the client and server, 
one of the underpinnings of distributed object operating 
environments is the interaction between the client, 
which is defined herein as an entity requesting a service, 
and a server, which is typically an object providing the 
service. For example, different scenarios include the cli- 
ent and server within the same process, in different 
processes on the same host computer, and on different 
processes running on different host computers. This cli- 
ent-object interaction can be discussed in terms of a cli- 
ent-server paradigm. By way of example, a client may 
be in a process running on a network computer, such as 
computer 12, which requests services from a target ob- 
ject in a different process running on a remote computer 
18. 

As will be appreciated by those of skill in the art, the 
entities which can be a client include, but are not limited 



to, a process running on a host computer, hereinafter 
referred to as a client process and a client host respec- 
tively, and an object, hereinafter referred to as a client 
object. Therefore, a client is any entity requesting a serv- 
5 ice, regardless of the nature of the entity For the sake 
of clarity, any object providing a service is hereinafter 
referred to as a target object. Additionally, the computer 
process under which a target object resides is referred 
to as a server process. 
10 Elaborating further on the terminology of client-^ 
server interactions, a client will "call 0 a target object to 
"invoke" a "method" that is executed by the target object. 
Note that while "call" and "invoke" can carry slightly dif- 
ferent meanings, herein the two terms are used inter- 
ns changeably and their meanings will be understood from 
the context of the discussion therein. Please note that 
the previous term "method 0 is a term of the art of object 
oriented programming and differs from the term "meth- 
od" classically used in drafting patent applications. In 
20 the following discussion, the Applicant believes that it is 
made clear (either by context or by a hint from the Ap- 
plicant) which meaning for the term "method 9 is used. 
In addition, the word "operation" is used in lieu of "object 
method" in- the appended claims. 
2S As is well known to those of skill in the art, an "object 
method" (or "method") is a procedure contained within 
an object which is made available to other entities, i.e. 
clients, for the purpose of requ esting services of that ob- 
ject. Thus the object performing the service for the client 
30 is the server, hence the term client-server. In calling an 
object method, the client may also pass those argu- 
ments, also referred to as parameters, necessary for the 
target object to perform the requested method. 

Referring next to Figs. 3 - 5, a few possible enumer- 
35 ations of a client-server model that are very represent- 
ative of a distributed object operating environment will 
be discussed. As is always the case, the client-server 
model will have a client entity, a target object, and some 
form of a server process. One such arrangement for im- 
40 piementing the following client-server models includes 
computers such as computer 30 of Fig. 2 interconnected 
over a network 1 4 as shown in Fig. 1 . 

Turning first to Fig. 3, a client-server model 300 
termed "host-to-host" is shown wherein client object 302 
45 and target object 304 exist on different host computers. 
The client object 302 resides in a client process 306 
which is executing on a client host computer 308. Client 
object 302 includes a surrogate object 310 which pro- 
vides a first indirection 312 to an object reference 314 
50 which in turn provides a second indirection 316 to the 
target object 304. In general, the surrogate object 310 
resides in the client process. However, those skilled in 
the art will appreciate that other configurations are suit- 
able. By way of example, the surrogate object may be 
ss a classic programming language object. Additionally 
there may be other surrogate objects which indirect to 
the single object reference 314. As used herein, an •in- 
direction" is a set of information, a pointer, etc., which 
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directs the client entity to a locator service which can 
direct the client entity to the object. By way of a descrip- 
tive analogy, if a client requested geographical direc- 
tions, an indirection would point the client to the location 
of a current map, or perhaps provide the client with a 5 
phonenumberofageographically astute individual. The 
idea of using an indirection (rather than direct address- 
ing) is useful for distributed objects as certain distributed 
objects (those of a persistent kind) may be mobile both 
from process to process and host computer to host com- io 
puter. 

Similar to the client object 302, the target object 304 
of Fig. 3 may reside in a server process 318 which is 
running on a server host 320. Other entities may reside 
on both the server host 320 and the client host 308. is 
These entities include but are not limited to additional 
processes and/or objects running under the client proc- 
ess, the server process, and/or the additional process- 
es. Two suitable processes are daemon_1 process 317 
running on client host 308 and daemon_2 process 321 20 
running on server host 320. Daemon processes typically 
run in the background and ire well known to those 
skilled in the art. 

Fig. 4 shows a "process-to-process" client-server 
model in which the client object 302 and the target object 25 
304 share the same host computer, the client/server 
host 322. However, client object 302 and target object 
304 reside within different processes. Similar to Fig. 3, 
the client object 302 exists in a client process 306 which 
is running on the client/server host 322. The client object 30 
302 includes a surrogate object 310 which provides an 
indirection 31 2 to an object reference 314 which in turn 
provides an indirection 31 6 to the target object 304. Tar- 
get object 304 exists within in a server process 318 
which is running on the client/server host 322. Akin to 35 
the "host-to -host" case, further entities such as process- 
es and/or objects may be resident on client/server host 
322. One such suitable process is daemon_1 process 
317. 

Fig. 5 shows a client-server model in which both cli- 40 
ent object 302 and target object 304 reside within the 
same process, the client/server process 324. Once 
again, the client object 302 uses a first surrogate object 
31 0 which holds (e.g. it has a first indirection 31 2 to) an 
object reference 31 4. In turn, object reference 31 4 pro- 45 
vides a second indirection 316 to the target object 304. 
In this case the second indirection 316 may just be a 
pointer to shared memory. This situation is perhaps the 
best of all three described cases. No network commu- 
nications is necessary, and since both objects are under so 
one process, they coexist in memory allocated to the 
client/server process 324. In the situation of Fig. 5, other 
entities such as objects may be resident in client/server 
process 324. For example, there may be other surrogate 
objects present in the client process 306, such as a sec- ss 
ond surrogate object 311, which may also hold the ob- 
ject reference 314. However some distributed object op- 
erating environments do not include surrogate objects. 



In these cases, the client 302 will utilize the object ref- 
erence 31 4 without a surrogate object. 

Two other typical client-server scenarios which are 
not shown in the above described Figs, will now be dis- ■ 
cussed briefly. The first set of scenarios involve the in- 
stances wherein the client is not an object. As will be 
appreciated by those skilled in the art, the issues which 
arise are very similar whether the client is an object or 
some other entity requesting service. The other scenar- 
io is one wherein the client object and the target object 
are the self-same object. This may occur when an object 
makes a recursive call upon itself. While the recursive 
call may appear unusual, this client-server interaction is 
a fairly common and powerf u I tool and may be dealt with 
in a manner similar to the case when a client object and 
a target object are unique but exist in the same process. 

Fig. 6 is a pictorial illustration of a client-server in- 
teraction wherein an ORB daemon process manages a 
multiplicity of server process and target objects. Fig. 6 
provides a generic paradigm for use in several specific 
embodiments of the present invention. The paradigm of 
Fig. 6 includes a client 350, a server process 352, and 
an ORB daemon process 354. In a step 356, client 350 
calls ORB daemon process 354 to request addressing 
information for a target object. Then, if necessary, ORB 
daemon process 354 starts server process 352 in a step 
358. Server process 352 corresponds to the server 
process for the requested target object. In a step 360, 
server process 352 responds to step 358 by indicating 
to ORB daemon process 354 that it is ready to provide 
services. In a step 362, ORB daemon process 354 re- 
turns addressing information to client 350. Once server 
process 352 is ready and client 350 has the addressing 
information, client 350 can call server 352 in a step 364 
and server 352 can pass, in a step 366, the results of 
the call of step 364. 

The paradigm of Fig. 6 provides a general overview 
of the client-server interaction in accordance with the 
present invention. The teaching of this invention is gen- 
erally directed to methods, apparatus, and data struc- 
tures which provide mechanisms for steps 358, 360, and 
362. Other steps are described in more detail in vander- 
bilt et. al.'s copending U.S. Patent Application Serial 
Number (Attorney Docket No. P717/SUN1P023) enti- 
tled "METHODS AND APPARATUS FOR MANAGING 
COLLECTIONS OF OBJECTS", which is incorporated 
herein by reference in its entirety. 

Turning next to Fig. 7, an ORB daemon process.400 
in accordance with a preferred embodiment of the 
present invention will now be described. ORB daemon 
process 400 is a background process executing qh a 
computer system (such as computer system 30 of Fig; 
2) which is part of a distributed network (such as network 
10 of Fig. 1). For example, one'suitable embodiment. of 
ORB daemon process 400 may be a process such as 
daemon process_2 321 of Fig. 3. According to one as^ 
pect of the present invention, it is contemplated that 
each computer system within the distributed object op- 
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erating environment has an ORB daemon process 400 
resident therein. 

In the embodiment of Fig. 7, ORB daemon process 
400 includes an active server table 402, a locator object 
404, and a server process registration object 406. Of 
course the ORB daemon process 400 may include a 
number of other objects as well as a number of threads. 
Locator object 404 and server process registration 406 
work in conjunction to provide a locator service as de- 
scribed later in more detail. However, locator object 404 
and server process registration object may be combined 
into one object which provides a locator service. An ob- 
ject adapter database 408 may be optionally resident in 
ORB daemon process 400. On the other hand, object 
adapter database 408 may be resident elsewhere in the 
distributed object operating environment. Either way, 
object adapter database 408 typically includes informa- 
tion regarding a plurality of objects such as server iden- 
tifiers, target object identifiers, a correlation between 
server and target object identifiers, an execdef for each 
target object, and object references for the target ob- 
jects. Locator object 404 includes an object method 
look-up target object 410 and server process registra- 
tion object 406 includes object methods register server 
41 2 and register new server 41 4. These object methods 
will be described in more detail immediately following 
the discussion of Fig. 8. 

Fig. 8 shows a data structure for active server table 
402 in accordance with one embodiment of the present 
invention. Active server table 402 is stored in memory 
such as RAM 34 or mass storage 38 of Fig. 2 which is 
allocated to ORB daemon process 400, and may be 
managed by one of many methods familiar to those of 
skill in the art. In the embodiment of Fig. 8, active server 
table 402 includes a plurality of server elements 419 
each including entries such as server identifier 420, 
server process state 422, addressing information 424, 
and server process identification 426. Server process 
state 422 may be either one of "running" or "starting. 0 
However, if the client requested process is not found in 
the active server table 402, the server process is said 
to have a state of "not active." 

Addressing information 424 may include a plurality 
of addresses for use in transport modes^such as (but 
not limited to) local transport, shared memory transport, 
or remote transport. Local transport occurs within the 
same process and is performed by copying data within 
the same address space. Shared memory transport (al- 
so called "same host" transport) is performed using the 
host operating system inter-process communication 
procedures. Remote transport is performed using net- 
working facilities. Each of these may vary depending up- 
on factors such as the operating system and the network 
communication protocol. Therefore addressing informa- 
tion 424 may vary accordingly. The design and imple- 
mentation of local, shared, and remote transport will be 
familiar to those skilled in the art. Modes of transport 
and appropriate addressing information are discussed 



in more detail in Brownell et. aL's copending United 
States Patent Application entitled "METHODS, APPA- 
RATUS, AND DATA STRUCTURES FOR MANAGING 
OBJECTS", Serial No. (Attorney Docket No. 
5 P721SUN1P025) which is incorporated herein by refer- 
ence in its entirety. 

Server process identification 426 is typically an 
identification number assigned to a process (at its incar- 
nation) by the operating system of the host computer 
10 under which the process is running. Server process 
identification 426 is unique in the sense that no two serv- 
er processes may exist concurrently with the same iden- 
tification number. However, as there is typically a finite 
number of server process identification numbers (by 
is way of example 32K is a suitable number), server proc- ■ 
ess identification numbers may get recycled. Server 
identifier 422 differs from server process identification 
426 in that server identifier 422 is assigned by the ORB 
and is typically forever unique within ORB daemon proc- 
20 ess 400. 

Referring again to Fig. 7, one embodiment of locator 
object 404 has an object method entitled look-up target 
object 410. When a client calls locator object 404 to in- 
voke look-up target object 410 (as in step 356 of Fig. 6), 
25 the client passes arguments which uniquely define a re- 
quested target object. Suitable arguments include data 
such as server identification 420 and/or a target object 
identifier. In response, locator object 404 will perform 
the requested service which in one embodiment in- 
30 eludes the steps of determining if the server process in 
which the target object resides is running, forking and 
executing the server process if it needs to be started, 
and returning server process addressing information to 
the client once the server process is ready to receive 
35 requests (as in step 362 of Fig. 6). One method aspect 
of the present invention which utilizes a locator object 
such as locator object 404 is described in further detail 
below with reference to Fig. 10. 

In a further embodiment, server process registra- 
40 tion object 406 of Fig. 7 has two object methods, these 
being register server 412 and register new server 414. 
When a client calls server process registration object 
406 to invoke register server 412, the client passes ar- 
guments which include a server identifier, a server proc- 
45 ess identification, and addressing information. Server 
process registration object 406 will store these argu- 
ments in active server table 402 and mark the server 
process state entry as "running" in the active server ta- 
ble. When a client calls server process registration ob- 
so ject 406 to invoke register new server 414, the client 
passes arguments which include a server process iden- 
tification, addressing information, and an object refer- 
ence. In one embodiment, server process registration 
object 406 will getthe server identifierf rom object adapt- 
ss er database 408, create a server process entry in active 
server table 402, store addressing information in active 
server table 402, mark server process state entry as 
"running 0 in active server table 402, and return the serv- 
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er identifier to the server process. A couple of method 
aspects of the present invention which utilize an object 
such as server process registration object 406 will be 
described in more detail below with reference to Figs, 
11-14. 5 

The method aspects of the present invention are 
discussed primarily from the viewpoint of the server and 
fall into substantially two categories. In the first category, 
methods for management (including fork and exec, and 
registration) of server processes are disclosed. A few 10 
preferred embodiments of the first case are described 
below in reference to Figs. 10, 12, and 13, each utilizing 
ORB daemon 400 of Fig. 7. In the second category, 
methods by which a server process starts (correspond- 
ing to the methods of Figs. 10,12, and 1 3) are disclosed, is 
A couple of preferred embodiments are described below 
with reference to Figs. 1 2 and 1 4. The need for the meth- 
ods of the present invention often arise in response to 
a client call, even though the viewpoint of the methods 
is that of the server. Therefore, for the sake of clarity, 20 
the discussion of the methods of Figs. 10-14 will be 
preceded by a brief discussiorTof the client-server inter- 
action from the viewpoint of the client. 

Referring next to Fig. 9 t a method 196 -of invoking 
a target object in accordance with one embodiment of 25 
the present invention will be described. The target object 
invocation method begins in a step 1 98 when a client 
object running in a client process on the client host ini- 
tiates the invocation of a target object. However, in the 
more general case, the client need not bean object. Typ- 30 
ically, the client object will only have an indirection to the 
target object (i.e. an object reference) and will know the 
target object's interface requirements (or at least the 
portion of the interface requirements that apply to the 
information it is seeking). Therefore, the invocation be- 35 
gins when the client object calls the target object with a 
call that identifies the target object using the object ref- 
erence and provides the arguments necessary to meet 
the target object's interface requirements. As illustrated 
in step 200, the client process responds to the client ob- 40 
ject's call with a call to the target object's surrogate 
which is located in the client process. Suitable methods 
for creating the target object surrogate and/or establish- 
ing a connection between the client object and the target 
object surrogate on the same machine and within the *s 
same process are known to those skilled in the art. In 
one example the object reference may be a pointer to 
the memory address of the surrogate. Typically a surro- 
gate is created when arguments to an invocation are un- 
marshaled or when a reply from an invocation is unmar- S( > 
shaled. By way of example, a suitable method of creat- 
ing the target object surrogate is described in vanderbilt 
et. al.'s copending United States Patent Application Se- 
rial No. (Attorney Docket No. P721/SUN1 P024) entitled 
"METHOD AND APPARATUS FOR DETERMINING ss 
THE TYPE OF AN OBJECT IN A DISTRIBUTED OB- 
JECT SYSTEM" which is incorporated herein by refer- 
ence in its entirety. 



Once the call is received by the target object surro- 
gate, the surrogate determines whether it already has 
addressing information for a target object servant exist/ 
ing on the server host. If the surrogate has the address- 
ing information, then process control goes directly to a 
step 216 where it establishes a network connection with 
the server process if necessary (as will be described be- 
low in more detail). On the other hand, if the surrogate 
does not have addressing information for the target ob- 
ject servant, then this information must be obtained prior 
to establishing a connection. In the latter case, the target 
object surrogate proceeds to step 204 where it locates 
the server host. It should be appreciated that the server 
host will be identified in the object reference. Therefore, 
the target object surrogate may contact the ORB which 
will provide it with the addressing information for the 
ORB daemon process running on the server host. 

Next, in a step 207, the target object surrogate es- 
tablishes a network connection with the ORB daemon 
process on the server host. However, if the surrogate 
already has an established connection with the ORB 
daemon process, it may not be necessary to establish 
a second connection. In any event, once an appropriate 
connection is established, the target object surrogate re- 
quests, in a step 209, that the ORB daemon process 
return addressing information for the server process on 
which the target object servant is running. One suitable 
way of requesting this information is to call the locator 
object to invoke a look-up method. Of course, although 
steps 207 and 209 are logically explained as separate 
steps, they can be accomplished simultaneously in a 
single call. Methods ol establishing connections be- 
tween processes are well known in the art. One suitable 
method of establishing the aforementioned process is 
described in Browne!! et. al.'s copending United States 
Patent Application Serial Number (attorney's docket no. 
P715/SUN1P018) entitled "METHOD AND APPARA- 
TUS FOR MANAGING CONNECTIONS FOR COMMU- 
NICATION AMONG OBJECTS IN A Dl STRI BUTED OB- 
JECT SYSTEM" which is incorporated herein by refer 2 
ence in its entirety. 

In response to steps 207 and 209, the ORB daemon 
must start and register the server process and then re-= 
turn addressing information to the client. A suitable 
method that the server host's ORB daemon process 
may go through will be described below with reference 
to Figs. 10-12. However, from the standpoint of the tar- 
get object surrogate, it simply receives the requested 
server process addressing information in a step 214. 
With this knowledge in hand, the surrogate can establish 
a direct connection with the appropriate server process 
in step 21 6. Of course, it is plausible that the client proc- 
ess has previously established a connection with the 
server process for any variety of reasons such as a pre- 
vious call to another target object running in this same 
server process. In this case, it may or may not be nec- 
essary (or desirable) to establish a second connection 
with the server process. 
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Once the connection is established in step 216, the 
target object surrogate will marshal the target object 
identifier and the arguments for the call in step 21 8. As 
used herein, to "marshal" data is to format the data in 
accordance with a predetermined network communica- 
tion protocol (e.g. the well known TCP/IP) in preparation 
for network transmittal. Additionally, to "marshal 8 data 
may be to format the data in accordance with a prede- 
termined protocol for shared memory transport. As will 
be appreciated by those skilled in the art, the network 
format and the shared memory format may be identical. 
The nature of the marshaling will depend entirely on the 
nature of the protocols used for communications on the 
particular network (or shared memory) that is in opera- 
tion and its implementation should be apparent to those 
of skill in the art. Then, in a step 220, the target object 
surrogate performs a remote call to the target object 
over the connection established in step 216. As a result 
of this call, in a step 222, the target object surrogate re- 
ceives and unmarshals the result of the target object call 
of step 216. Once the results have been unmarshaled, 
the target object surrogate returns the unmarshaled re- 
sults to the client object in a step 225. The client may 
than use the returned- results appropriately 

One method aspect of the present invention will be 
described now with respect to Fig. 10. The method of 
Fig. 10 is a response to step 209 of Fig. 9 and in one 
embodiment is performed by an ORB daemon process. 
The thread of execution of the method of Fig. 10 begins 
in a step 500 when locator object 404 receives a look- 
up call for the target object. Note that this look-up call is 
received via the ORB daemon process which (if neces- 
sary) may prepare the call for the locator object 404. For 
example, the ORB daemon process may unmarshal the 
call and any arguments. In addition to receiving this in- 
vocation, the locator object 404 will receive the neces- 
sary arguments such as the target object identifier. Next, 
in a step 502, locator object 404 accesses the object 
adapter database 406 to get a server identifier 420 that 
corresponds to the requested target object. In one suit- 
able implementation, the locator object 404 searches 
the object adapter database 408 using the target object 
identifier received in step 500 as a key to find the cor- 
responding server identifier. Once locator object 404 
has the server identifier 420, it looks through an active 
server table 402 to determine a state of the server proc- 
ess in a step 504 by reading the server state entry 422. 
In one embodiment, the locator object 404 uses the 
server identifier 420 as a key to find the corresponding 
state entry 422 in the active server table 402. As dis- 
cussed previously with respect to Fig. 8, the possible 
. states of the server process include running, starting, 
and not active. 

In step 506 it is determined if the server process is 
listed in active server table 402. If it is listed, then control 
branches to a step 508 where it is determined if the serv- 
er process state is starting. If the server process state 
is not starting, then the server process is running and 



control proceeds to a step 510 where addressing infor- 
mation 424 is read from active server table 402 and then 
returned to the client. Note that the client may be local 
or remote and thus transport must be handled accord- 
5 ingly. For example, if the client is remote, addressing 
information 424 must be marshaled in preparation for 
network transmittal. 

Traveling across the YES branch of step 503 (i.e. 
the server process state is starting) to a step 513, locator 
10 object 404 must wait until state entry 422 of active server 
table 402 transitions from starting to running. As is well 
known to those skilled in the art, this "wait state" may 
be accomplished by "locking" the thread of execution for 
locator object 404. In step 51 3 the thread is locked until 
15 the server process state is running. Note that the server 
process may be running or starting even if the currently 
requested target object has not previously been re- 
quested. This is because the present invention teaches 
that multiple objects may reside under a single process. 
20 The present invention enables this feature by checking 
and managing server processes so that redundant proc- 
esses are not necessarily started for each requested tar- 
get object. In any event, once the server process is run- 
ning, control proceeds to step 510 where addressing in- 
25 formation is returned to the client. Once again, the ad- 
dressing information may be marshaled in preparation 
for network transmittal. 

If the target object requested in step 500 was a le- 
gitimate, existing target object, then a corresponding 
30 server identifier will be found in the object adapter da- 
tabase 408. However, it is possible that no clients have 
previously requested a target object which resides in the 
server process corresponding to this server process 
identifier. In this case, the server process is not active 
35 and its server identifier will not be listed in the active 
server table 402. Thus the server process state is said 
to be not active. Accordingly, proceeding across the NO 
branch of step 506 (i.e. server identifier is not listed in 
active server table 402), in a step 51 4 locator object 404 
40 creates a server process entry in active server table 402 
and marks server process state 422 as starting. By 
marking the state as starting, the locator object 514 pre- 
vent errors which may occur if another client were to 
make a request which involved this server process. 
45 Next, in a step 5 1 6, locator object 404 accesses ob- 
ject adapter database 408 to get the execdef for the tar- 
get object. In other embodiments, the execdef may be 
obtained during other steps such as step 502. In expla- 
nation, the execdef may be thought of as a startup pro- 
50 cedure for the server process. For example, an execdef 
may include a directory path, an executable filename, 
and a list of arguments. Once locator object 404 has the 
execdef for the target object, it proceeds to "fork and 
exec" the server process in a step 518 using the exec- 
55 def . That is, a new thread of execution for a new process 
offshoots from the thread of Fig. 10 and proceeds to ex- 
ecute the program listed as the executable filename, 
hence the phrase "fork and exec." This phrase will be 
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familiar to those of skill in the art. After the fork and exec 
of step 51 3, the locator object 404 proceeds to step 5 1 3 
wherein it must wait until server process state entry 422 
of active server table 402 transitions from starting to run- 
ning. Once the server process is running, control pro- s 
ceeds to step 510 where addressing information is re- 
turned to the client. 

In any event, once the addressing information is re- 
turned to the client in step 510, control proceeds to a 
step 512 where the operation look-up target object is io 
complete. Additional embodiments of the method of Fig. 
10 are envisioned. In particular, there may be additional 
states corresponding to the server process stats 422 
such as "unavailable" or "nonexistent." In either case, 
appropriate steps such as returning an error message is 
to the client may be performed by locator object 404, 
Another state may be "forward all requests." In thiscase, 
the locator object 404 may return addressing informa- 
tion for a "replacement" target object and/or server proc- 
ess. 20 

Other variations on the method of Fig. 10 are envi- 
sioned. During normal operation of a distributed object 
operating environment there may arise situations 
wherein the target object and/or server process may be 
temporarily (or permanently) unavailable. For example, 2$ 
maintenance operations such as backing up, fixing 
code, or installing new objects may disable the target 
object and/or server process. According to one embod- 
iment of the present invention, there may be three pos- 
sible states: long hold down, short hold down, and no 30 
hold down. In the case of no hold down, both the target 
object and the server process are available and the lo- 
cator object 404 thread of execution may proceed ex- 
actly as described in reference to Fig. 1 0. In the case of 
short hold down, the thread of execution is blocked tern- 35 
porarily, similar to step 513 of Fig. 10. This case would 
be appropriate if the delay was relatively short. In the 
case of long hold down, an error message would be re- 
turned to the client. This would be appropriate if the tar- 
get object and/or server process was permanently una- 40 
vailable, or unavailable for a relatively long period of 
time. One suitable place to store the hold down informa- 
tion is within the execdef . Then, step 504 of Fig. 1 0 could 
be expanded to further include the step of determining 
the hold down and performing the appropriate steps. 45 

Referring next to Fig. 11, a method of starting a 
server process in accordance with one embodiment of 
the present invention will now be described. By way of 
example, the server process may start in a step 550 in 
response to the fork and exec step 51 8 of Fig. 10. Next, so 
in a step 552, the server process calls a transport serv- 
ice to create a communications port and form its ad- 
dressing information for the server process. As will be 
appreciated by those skilled in the art, the transport 
service may be implemented as part of the host compu- ss 
ter operating system or as part of the distributed object 
operating environment. Then, in a step 554, the server 
process calls the server process registration object 406 
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to invoke the register server operation, passing server 
identifier 420, addressing information 424, and server 
process identification 426 as arguments. With this infor- 
mation the server process registration object 406 can 
uniquely register the server process as described in fur- 
ther detail below with respect to Fig. 12, thereby perpet- 
uating the advantages of the present invention. Once 
this. call is made and the server process is registered, 
the server process is ready to handle requests in a step 
556. 

Turning now to Fig. 12, a method of registering a 
server process in an active server table 402 in accord- 
ance with one embodiment of the present invention will 
be described. By way of explanation, a server process 
registration object may perform the registration in re- 
sponse to an invocation as in step 554 of Fig. 11. In a 
step 570, server process registration object 406 re- 
ceives a register server invocation which includes argu- 
ments such as server identifier 420, addressing infor- 
mation 424, and server process identification 426. Next, 
in a step 572, server process registration object 406 
stores addressing information 424 in active server table 
402. Note that an entry for this server process (identify- 
ing it by server identifier 420) was created in a step such 
as step 514 of Fig. 10. Then, in a step 574, server proc- 
ess registration object 406 marks server process state 
422 as running. Once the state is marked running, serv- 
er process registration object 406 has completed the re- 
quested service and is done in a step 576. 

As will be appreciated, the methods of Figs. 9-12 
may all be woven into one client-server interaction en :: 
compassing the steps 356 - 362 as described in refer- 
ence to the client-server paradigm of Fig. 6. Each of the 
Figs. 9-12 may be interpreted to describe a separate 
thread of execution, and one embodiment of the present . 
invention may be implemented this way Additionally, 
these threads may be collapsed into a single thread for 
implementation on a single-threaded system. Ths ad- 
vantages of different threading schemes, as well as their 
implementation and construction, will be well familiar to 
those skilled in the art. Alternatively, various embodi- 
ments would provide methods for the different client- 
server interactions described above with reference to 
Figs. 3 - 5. In light of the preceding it will be apparent to 
those skilled in the art how to construct and implement 
these and still further embodiments, all which fall within 
the scope of the present invention. 

Underlying the above discussion of Figs. 9-12 was' 
the assumption that an ORB daemon process 400 start- 
ed a server process. However, this is not always the 
case. For instance, a client may pass a call directly to 
the target object yet the target object and/or the server- 
process may not be active. In another instance, a dis- 
tributed object and/or its corresponding server process 
may wish to activate due to one of many other causes 
(e.g. a particular object and/or process always executes 
at power up). In either instance, a mechanism is re- 
quired for server processes to "self -start" (i.e. start-up 
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and register) themselves. A couple of methods relating 
to S9lf-starting servers are described below with respect 
to Figs. 13 and 14. 

Referring to Fig. 1 3, a method for a server process 
to self-start (i.e. start and register itself) in accordance 
with one embodiment of the present invention will be dis- 
cussed. In a first step 600, a client calls to invoke an 
object method which can roughly be described as "be- 
come server. 0 In one embodiment the client also passes 
an object reference to identify the desired target object 
and thereby designate the corresponding server proc- 
ess. In other embodiments, the initial step 600 may sim- 
ply correspond to an object self initiating its self-start. In 
any event, after initial step 600, the object, in a step 602, 
calls transport to create a port for the server process 
and form addressing information for the server process. 
Again, the addressing information may include address- 
es for remote, shared memory, and local modes of trans- 
port. Note that step 602 is analogous to step 552 of Fig. 
11. 

Once the server process addressing information is 
formed, the server process needs to register with the 
ORB daemon process. Therefore, in a step 604, the 
■ server process gets the object reference for server proc- 
ess registration object 406. The object reference for the 
server process registration object 406 provides the in- 
direction necessary for communication with the server 
process registration object 406. By way of example, the 
server process may use the ORB to obtain this object 
reference. Once it has the object reference, the server 
process, in a step 606, calls server process registration 
object 406 to invoke object method register new server 
414 and passes server process identification 426, ad- 
dressing information 424, and the object reference for 
the target object as arguments. If the server process 
knows its server identifier 420, then it may pass this in 
lieu of the object reference for the target object. One 
embodiment of the server process registration object's 
response to this invocation is described below with re- 
spect to Fig. 14. Then (if necessary), in a step 608, the 
server process receives back its server identifier 420 
from the server process registration object 406. Thus 
the server process is registered, uniquely defined, and 
ready to handle requests in a step 610. 

Turning now to Fig. 14, one method for a server 
process registration object 406 to register a new object 
will be discussed. In a step 620, server process regis- 
tration object 406 receives a register new server 41 4 in- 
vocation with arguments including server process iden- 
tification 426, addressing information 424, and the ob- 
ject reference for the target object. By way of example, 
this invocation may have been generated by step 606 
of Fig. 13. Next, in a step 622, server process registra- 
tion object 406 uses the object reference for the target 
object to get server identifier 420 from object adapter 
database 408. Then, in a step 624, server process reg- 
istration object 406 performs the steps of: creating sen/- 
er process entry in active server table 402; storing ad- 



dressing information 424 in active server table 402; and 
marking server process state entry 422 as running. Now 
the new server process is registered and in a step 626 
server process registration object 406 passes server 
s identifier 420 to the server process. Note that step 626 
sends the information that is received in step 608 of Fig. 
13. Then, the method of Fig. 14 is complete in a step 
628. 

Although only a few embodiments of the present in- 

10 vention have been described, it should be understood 
that the present invention may be embodied in many 
other specific forms without departing from the spirit or 
scope of the invention. The client-server models dis- 
cussed with reference to Figs. 3 - 5 are only samples 

15 and in no way should be construed as limiting. By way 
of example, the "host-to-host" model could be extrapo- 
lated to include multiple target objects. That is, the first 
target object 304 could simply be an object reference 
which indirects to another target object, perhaps in an- 

20 other distributed object environment. Thus multiple 
server processes may get started as a result of the initial 
request for service. Or, the first target object could per- 
form a portion of the requested service and then make 
its own call to a second target object before responding 

25 to the first client object 302. As will be appreciated, the 
possible enumerations take on many embodiments, all 
of which fall within the scope of the present invention. 
Furthermore, each of these instances can be managed 
by the disclosed ORB daemon process through various 

30 embodiments which will be apparent to those skilled in 
the art. 

The data structure and location of active server ta- 
ble 402 may be varied greatly and yet fall within the 
scope of the present invention. As a first example, active 

35 server table 402 may be located in a process separate 
from ORB daemon process. Additionally, the informa- 
tion stored in active server table 402 could be main- 
tained in object adapter database 408 and vice versa. 
Furthermore, different distributed object operating envi- 

40 ronments may have different requirements for uniquely 
identifying server processes. In these cases, the entries 
in active server table 402 may expanded and/or con- 
tracted accordingly. Still further, each of these may re- 
quire a specific arrangement of the described data struc- 

45 tures. Construction and implementation of each of these 
numerous embodiments will be apparent to those skilled 
in the art. 

As will be appreciated by those skilled in the art of 
distributed object systems, the underlying ideas behind 

so the described methods of managing server processes 
and target objects can be implemented in a wide variety 
of alternative embodiments, of which there far too many 
to discuss in detail. However, since the underlying phi- 
losophy has been described, various alternatives will be 

55 clear to those skilled in the art. By way of example, the 
object methods contained in locator object 404 and 
server process registration object 406 may be spread 
over several additional objects or combined into one ob- 
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ject which could be termed the locator service. Addition- 
ally, other process for execution control (besides 
threads) may be used to implement the present inven- 
tion. 

Therefore, the present examples are to be consid- s 
ered as illustrative and not restrictive, and the invention 
is not to be limited to the details given herein, but may 
be modified within the scope of the appended claims. 

10 

Claims 

1. A daemon process for use on a computer system 
in a distributed object operating environment, said 
distributed object operating environment including is 
a plurality of distributed objects which are intended 

to reside in a corresponding plurality of server proc- 
esses, said daemon process operable to manage 
that portion of said plurality of distributed objects 
which reside on said computer system and that por- 20 
tion of said plurality of server processes which ex- 
ecute on said computer system, said daemon proc- 
ess including: 

an active server table arranged to maintain en- 2s 
tries regarding a plurality of server processes, 
said entries including a server identifier, a serv- 
er process state, and server process address- . 
ing information; and 

a locator service operable to access said active 30 
server table to provide server process address- 
ing information for said plurality of server proc- 
esses, said locator service further operable to 
register a server process in said active server 
table. 35 

2. A daemon process as described in claim 1 further 
including an object adapter database, said object 
adapter database including: 

40 

a plurality of target object identifiers; 

a plurality of server identifiers, each server 

identifier corresponding to at least one of said 

plurality of target object identifiers; and 

a plurality of object references, each object ref- 45 

erence corresponding to one of said plurality of 

target object identifiers, 

3. A daemon process as described in claim 1 wherein 
said locator service includes a locator object ar- so 
ranged to perform said operation of accessing said 
active server table to provide server process ad- 
dressing information, said operation performed in 
response to a request from a client. 

55 

4. A daemon process as described in claim 1 wherein 
said locator service includes a server process reg- 
istration object arranged to perform said operation 



of registering a server process in the active server 
table. 

5. A distributed object operating environment com- 
prising: 

a plurality of computer systems; 
a computer network interconnecting said plu- 
rality of computer systems; and 
at least one daemon process as recited in claim 
1. 

6. A computer system for use in a distributed object 
operating environment, said computer system com- 
prising: 

a central processing unit; 
a memory accessible by said central process- 
ing unit, said memory including a plurality of 
distributed objects; and 

a locator service implemented on said compu- 
ter system that manages said plurality of dis- 
tributed objects and a plurality of server proc- 
esses which may be implemented on said com- 
puter system. 

7. A computer system as recited in claim 6 further in- 
cluding an input/output device which may commu- 
nicate with said distributed object operating envi- 
ronment and wherein said locator service includes: 

a computer implemented receiver for receiving 
a look-up call for a target object from a client, 
said look-up call received via said input/output 
device; 

a computer implemented mechanism for ob- 
taining a server .identifier for said target object; 
a computer implemented evaluator for deter- 
mining a state of a server process correspond- 
ing to said target object, said server process 
uniquely defined within said computer system 
by said server identifier, said state of server 
process being one of the group consisting of 
running, starting, and not active; and 
a computer implemented transmitter for return- 
ing addressing information corresponding to 
said server process to said client, said address- 
ing information returned via said input/outjbiri 
device. 

8. A computer system as recited in claim 7 wherein 
said transmitter is arranged to operate immediately 
upon said evaluator determining that said state is 
running. 

9. A computer system as recited in claim 7 further irv 
eluding a wait device operable to wait until said state 
transitions from starting to running. 
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10. A computer system as recited in claim 7 wherein 
said mechanism for obtaining a server identifier for 
said target object is operable to access a first data- 
base stored in said memory to obtain said server 
identifier. 

11. A method as recited in claim 10 wherein said first 
database is an object adapter database. 

12. A computer system as recited in claim 10 wherein 
said evaluator is operable to look up said state in a 
second database stored in said memory. 

13. A computer system as recited in claim 12 wherein 
said second database is an active server table, 

14. A computer system as recited in claim 12 wherein 
said first and second database are the same data- 
base. 

15. A computer system as recited in claim 12 further 
including: 

a computer implemented creator for creating a 
server process entry in said second database, 
said server process entry including a server 
identifier and a server process state; 
a computer implemented marking device for 
marking said server process state as starting in 
said second database; 

a computer implemented accessing device for 
accessing said first database to get an execdef 
for said target object; 

a computer implemented starter for starting 
said server process using said execdef for tar- 
get object; and 

a computer implemented wait device operable 
to wait until said server process state for said 
server process transitions from starting to run- 
ning. 

16. A computer system as recited in claim 15 wherein 
said server process includes: 

a second computer implemented receiver for 
receiving a server process identification 
number from an operating system of said com- 
puter system; 

a computer implemented communications port 
creator for creating a communications port for 
said server process; 

a computer implemented address device for 
forming addressing information for said server 
process; 

a second computer implemented transmitter for 
calling a server process registration object res- 
ident in said daemon process, said call opera- 
ble to invoke a register server operation, said 
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call passing said addressing information, said 
server process identification number, and said 
server identifier to said server process registra- 
tion object. 

17. A computer system as recited in claim 16 wherein 
said server process registration object includes: 

a register server operation receiver for receiv- 
ing a call invoking said register server opera- 
tion; 

a database device for storing said addressing 
information in said second database; and 
a state marking device for marking said server 
process state entry as running. 

18. A distributed object operating environment com- 
prising: 

a plurality of computer systems wherein at least 
one of said plurality of computer systems is a 
computer system as recited in claim 6; and 
a computer network interconnecting said plu- 
rality of computer systems. 

19. A computer system for use in a distributed object 
operating environment, said computer system com- 
prising: 

a central processing unit; 
a memory accessible by said central process- 
ing unit; 

a forking mechanism to fork a new thread of ex- 
ecution from a thread of execution executing on 
said computer system; and 
a server process implemented on said compu- 
ter system, said server process including: 

a first device for receiving a server process 
identification number from an operating 
system of said computer system; 
a second device for creating a communica- 
tions port for said server process; 
an address device for forming addressing 
information for said server process; and 
a register server transmitter for calling a 
server process registration object resident 
in a process executing on said computer 
system, said call operable to invoke a reg- 
ister server operation, said call passing 
said addressing information, said server 
process identification number, and said 
server identifierto said server process reg- 
istration object. 

20. A computer implemented method for managing a 
plurality of server processes which are intended to 
execute on a computer system, said computer sys- 
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tem for use in a distributed object operating envi- 
ronment, said method performed by a daemon 
process resident on said computer system, said 
method comprising the steps of: 

receiving under computer control a look-up call 
for a target object, said look-up call originating 
from a client; 

obtaining under computer control a server iden- 
tifier for said target object; 
determining under computer control a state of 
a server process corresponding to said target 
object, said server process uniquely defined 
within said computer system by said server 
identifier; and 

returning under computer controf addressing 
information corresponding to said server proc- 
ess to said client. 

21. A method as recited in claim 20 wherein said state 
is determined to be running and therefore said step 
of returning addressing information is performed 
immediately. 

22. A method as recited in claim 20 wherein said state 
is determined to be starting and therefore said 
method further includes a step -of waiting under 
computer control until said state transitions from 
starting to running, said watting step performed pri- 
or to the step of returning addressing information. 

23. A method as recited in claim 20 wherein the step of 
obtaining a server identifier for said target object in- 
cludes accessing under computer control a first da- 
tabase. 

24. A method as recited in claim 23 wherein said first 
database is an object adapter database. 

25. A method as recited in claim 23 wherein the step of 
determining a state of a server process includes 
looking up under computer control said state in a 
second database. 

26. A method as recited in claim 25 wherein said sec- 
ond database is a active server table. 

27. A method as recited in claim 25 wherein said first 
and second database are the same database. 

28. A method as recited in claim 25 wherein said server 
process is not listed in said second database and 
therefore the method further includes the following 
steps performed prior to said return addressing in- 
formation step: 

creating under computer control a server proc- 
ess entry in said second database, said server 



process entry including a server identifier and 
a server process state; 

marking under computer control said server 
process state as starting in said second data- 

5 base; 

accessing under computer control said first da- 
tabase to get an execdef for said target object; 
starting under computer control said server 
process using said execdef for target object; 

10 and 

waiting under computer control until said server 
process state for said server process transk 
tions from starting to running. 

is 29. A method as recited in claim 28 wherein said server 
process responds to said step of starting said server 
process by performing the steps of: 

receiving under computer control a server proc- 
20 ess identification number from an operating 

system of said computer system; 
creating under computer control a communica- 
tions port for said server process; 
forming under computer control addressing in- 
25 formation for said server process; 

calling under computer control a server process 
registration object resident in said daemon 
process, said call operable to invoke a register 
server operation, said call passing said ad- 
30 dressing information, said server process iden- 

tification number, and said server identifier to 
said server process registration object. 

30. A method as recited in claim 29 wherein said server 
35 process registration object performs the steps of: 

receiving under computer control a call invok- 
ing said register server operation; 
storing under computer control said addressing 
*o information in said second database; and 

marking under computer control said server 
process state entry as running. 

31. A computer implemented method for a server proe- 
ms ess executing on a computer system, said server 

process having a server identifier, said computer 
system for use in a distributed object operating en- 
vironment, said method comprising the steps oi: 

50 receiving under computer control a server proc- 

ess identification number from an operating 
system of said host computer; 
creating under computer control a communica- 
tions port for said server process; 

55 forming under computer control addressing in- 

formation for said server process; 
calling under computer control a server process 
registration object resident in a process execut 1 
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ing on said computer system, said call operable 
to invoke a register server operation, said call 
passing said addressing information, said serv- 
er process identification number, and said serv- 
er identifier to said server process registration 
object. 

32. A computer implemented method for a server proc- 
ess registration object resident in a process execut- 
ing on a computer system, said computer system 
for use in a distributed object operating environ- 
ment, said method comprising the steps of: 

receiving under computer control a call invok- 
ing a register server operation, said call includ- 
ing a server process identification number, a 
server identifier corresponding to said server 
process identification number and addressing 
information corresponding to said server iden- 
tifier; 

storing under computer control said addressing 
information in a database; and 
.marking under computer control a server proc- 
ess state entry in said database as running. 

33. A computer implemented self-start method for a 
server process executing on a computer system, 
said computer system for use in a distributed object 
operating environment, said method comprising the 
steps of: 

receiving under computer control a become 
server invocation from a client; 
. receiving under computer control an object ref- 
erence for a target object; 
receiving under computer control a server proc- 
ess identification number from an operating 
system of said computer system; 
creating under computer control a communica- 
tions port for said server process; 
forming under computer control addressing in- 
formation for said server process; 
obtaining under computer control an object ref- 
erence for a server process registration object 
from an object request broker; 
calling under computer control said server 
process registration, said call operable to in- 
voke a register new server operation, said call 
passing said addressing information, said serv- 
er process identification number, and said ob- 
ject reference for said target object to said serv- 
er process registration object; and 
receiving under computer control a server iden- 
tifier corresponding to said server process. 

34. A computer implemented method for a server proc- 
ess registration object in response to a call invoking 
a register new server operation as recited in claim 
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33, said method including the steps of: 

obtaining under computer control a server iden- 
tifier from an object adapter database; 
creating under computer control a server proc- 
ess entry in an active server table; 
storing under computer control said addressing 
information in said active server table; 
marking under computer control a server proc- 
ess state entry in said active server table as 
running; and 

sending under computer control said server 
identifier to said server process. 
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